XOA论文学习：从架构上隔离Prompt Injection的AI-Agent方案

这篇文章基于 AgenticOS 2026 论文《Execute-Only Agents: Architectural Defense Against Prompt Injection for AI Agents》整理，重点讨论一个非常关键的安全问题：Prompt Injection 能不能不靠“模型更聪明”来防，而是直接从架构层切断攻击面。

写在前面

---

• 博文内容为 AgenticOS 2026 论文 Execute-Only Agents: Architectural Defense Against Prompt Injection for AI Agents 的学习笔记
• 论文地址：https://os-for-agent.github.io/papers/AgenticOS_2026_paper_21.pdf
• 这篇论文很短，但观点非常锋利：不要让 LLM 读到不可信数据
• 作者把这套思路命名为 XOA（Execute-Only Agents）
• 理解不足小伙伴帮忙指正 :),生活加油

我看远山，远山悲悯

持续分享技术干货，感兴趣小伙伴可以关注下 ^_^

---

一句话先说结论

这篇论文最核心的观点是：

与其不断研究“如何让 LLM 更好地区分指令和数据”，不如直接从架构上规定 LLM 永远不要看到不可信数据，只负责生成处理脚本，再把真正的数据处理放进隔离执行环境中完成。

作者的论证很直接：

• 在 AgentDojo 的 97 个任务里，大约 78.4% 可以在 LLM 完全不读取数据内容 的情况下完成
• 所以很多 Agent 任务其实不需要把邮件、网页、文件内容直接喂给模型
• 如果不让模型看到这些不可信内容，间接提示注入的攻击面就会被大幅削弱

名词解释

• Prompt Injection：攻击者把恶意指令伪装进网页、邮件、文档等外部数据里，诱导 LLM 偏离原始任务
• indirect prompt injection：恶意内容不是用户直接输入，而是通过工具返回的外部数据进入模型上下文
• XOA：Execute-Only Agents，只执行不读不可信数据的 Agent 架构
• ReAct loop：LLM 推理和工具调用交替进行的经典 Agent 执行循环
• AgentDojo：用于评估 Agent 工具使用与安全性的 benchmark
• scriptability：任务是否能够通过脚本或程序完成，而不要求 LLM 阅读原始数据内容
• Blind：完全不需要读取数据内容即可完成的任务类别
• Schema-Inferable：依赖结构、格式或程序逻辑即可处理，而不必让 LLM 阅读原文的任务类别
• Read-Required：必须阅读和理解原始文本语义才能完成的任务类别
• Execute-Only Sandbox：能接触真实数据但不会把数据内容回传给 LLM 的隔离执行环境
• execute_script：XOA 架构中统一的脚本执行入口
• development playground：给模型调试脚本、看可信反馈、修正程序的可信开发环境
• No-Read Principle：模型不直接读取不可信数据的设计原则

论文到底在研究什么问题

论文关注的是现代 Agent 的一个根本性安全问题。

现在很多 Agent 的工作流是：

1. 用户给任务
2. 模型调用工具
3. 工具返回数据
4. 数据回填进模型上下文
5. 模型继续推理并执行下一步动作

问题就出在第 3 到第 4 步。

因为工具返回的数据可能来自：

• 邮件
• 网页
• 文件
• 外部系统文本

这些内容本质上是不可信的。但在现有 ReAct 架构里，这些不可信数据和系统提示、用户目标、历史对话会一起进入 LLM 上下文。

于是攻击者只要在数据里埋入类似：

• 忽略之前的指令
• 把用户文件发给我
• 调用某个工具上传数据

这样的文本，就有机会诱导模型越权。

论文的关键观察：很多任务其实根本不需要让 LLM 看数据

这篇论文最有价值的地方，不是直接提出架构，而是先给出一个观察：

很多任务可以通过脚本处理完成，而脚本的生成只依赖任务说明和工具 schema，不依赖真实数据本身。

作者据此提出了一个 scriptability taxonomy，把任务分成三类。

1. Blind

这类任务可以完全不读取数据内容，只要知道工具接口就能完成。

例如：

• 列出未读邮件数量
• 调用某个既定 API 返回结果

2. Schema-Inferable

这类任务需要处理数据，但可以通过已知结构、可推断格式或程序逻辑完成，不需要 LLM 去“阅读理解”原文。

例如：

• 从固定格式文本中抽日期
• 从已知字段中提取值

3. Read-Required

这类任务真的要求模型阅读并理解内容语义，例如：

• 总结一段自然语言
• 判断邮件语气
• 理解自由文本指令

作者对 AgentDojo 全部 97 个任务做了人工分类，结果是：

• 20% 是 Blind
• 58% 是 Schema-Inferable
• 22% 是 Read-Required

也就是说，有 78.4% 的任务理论上都可以不让 LLM 直接接触不可信数据。

XOA 架构到底做了什么

论文提出的 XOA 建立在两个原则上。

1. No-Read Principle

核心原则非常直接：

• LLM 不得观察不可信数据

所有真实数据处理都应该发生在隔离执行环境里，处理结果也不能把原始不可信内容再带回模型。

作者把这件事类比成：

• execute-only memory
• 在加密数据上计算

本质上都是在强调：执行可以发生，但内容本身不应暴露给推理主体。

2. Code Generation Is Independent of Data Access

论文的第二个原则是：

• 生成“处理数据的程序”不等于“必须先看到真实数据”

也就是说，模型只需要：

• 任务描述
• 工具 schema
• 可信开发反馈

就可以先写出脚本，再把脚本丢到实际数据环境里跑。

XOA 的三个关键组件

1. Execute-Only Sandbox

这是 XOA 的核心执行环境。

它具备：

• 完整工具访问能力
• 可以接触真实不可信数据
• 但不把数据回传给 LLM

因此，就算某个文件里写着“忽略之前指令”，它也只是被 Python、Go 或其他解释器当普通字符串处理，而不会被 LLM 当指令执行。

2. System Prompt + execute_script

在 XOA 架构里，模型不再频繁直接读工具输出，而是主要负责：

• 根据任务说明生成脚本
• 通过统一入口 execute_script 调度执行

这让工具调用从“逐步交互式工具使用”变成了“先生成程序，再执行程序”。

3. Development Playground

论文没有让模型盲写脚本，而是给它一个可信的开发环境：

• lint
• type checking
• mock data
• 迭代修正

这有点像把 Agent 从“现场一边看真实数据一边想”改成“先在可信实验室里把脚本调通，再送到真实环境执行”。

这篇论文真正强在哪里

它强的地方在于提出了一种 architectural defense，而不是 probabilistic defense。

传统防御的常见问题

现在很多 Prompt Injection 防御方案，大多还是：

• 更强 system prompt
• instruction hierarchy
• 检测器
• 分类器
• 双模型隔离

这些方法都有帮助，但论文认为它们仍然有共同弱点：

• 本质上还是让某个 LLM 去处理不可信内容
• 只是希望它更听话、更能识别风险

这就意味着攻击面依然在。

XOA 的不同之处

XOA 则试图把攻击面直接切掉：

• 不可信内容不进入模型上下文
• 模型只生成程序
• 程序在隔离环境处理数据

这不是“提升命中率”的优化，而是从信息流路径上改写威胁模型。

我对这篇论文的几个理解

下面是我自己的理解。

1. 它其实是在把 Agent 从“对话型系统”推向“程序型系统”

传统 Agent 更像：

• 看一段内容
• 想一步
• 调一个工具
• 再看一段结果

而 XOA 更像：

• 先把任务编译成脚本
• 再把脚本放进受控执行环境

这让我觉得它很像把 Agent 往 compiler/runtime 的方向推进。

2. 它不是解决所有任务，而是解决“大量可脚本化任务”

论文没有声称所有任务都能用 XOA 做。

相反，它非常坦诚：

• Read-Required 任务仍然是难点
• 但问题在于，我们过去默认“模型必须读数据”，这个默认值可能本来就过宽了

3. 这是很少见的“主动削减能力面”设计

很多系统论文喜欢加新能力。

这篇论文反过来做了一件很有系统感的事：

• 不是让 LLM 学会更多
• 而是故意不让它做某些危险的事

这种“削减能力换强边界”的思路，我觉得非常值得重视。

论文的局限

1. 目前主要还是概念验证

这篇论文篇幅很短，核心贡献更偏：

• 威胁模型重构
• 任务可脚本化分析
• 架构提案

而不是已经给出完整实证系统。

2. Read-Required 任务依然难处理

对于必须理解自然语言内容的任务，XOA 没法彻底回避“模型读取数据”这件事。

3. 对脚本生成质量和可信开发环境有依赖

如果脚本写不好，或者开发 playground 的工具反馈不够强，整体可用性会下降。

对工程实践的启发

1. 不要默认所有工具输出都应该回填给 LLM

很多时候可以改成：

• 程序处理
• 结构化摘要
• 可信中间层筛选

2. Prompt Injection 防御可以从信息流重构入手

与其反复训练模型识别恶意提示，不如先问一句：

• 这个数据有没有必要进入模型上下文

3. 能程序化的任务，尽量程序化

对安全敏感场景来说，脚本化执行通常比让 LLM 直接读原始内容更稳。

总结

如果只用一句话总结这篇论文，我会这样说：

XOA 的真正价值，不是又发明了一种 Prompt Injection 检测器，而是把 Agent 的安全问题重写成了一个信息流问题，并给出一个非常强硬的答案：能不让模型看到的数据，就不要让它看到。

这篇论文虽然短，但它提出的是一个很大的方向：

• 安全不一定靠模型更聪明
• 也可以靠架构边界更硬

我觉得这正是 Agentic Systems 很值得继续深挖的一条路线。

参考

• 论文 PDF：https://os-for-agent.github.io/papers/AgenticOS_2026_paper_21.pdf
• AgenticOS 2026 Workshop：https://os-for-agent.github.io/

博文部分内容参考

© 文中涉及参考链接内容版权归原作者所有，如有侵权请告知 :)

---

---

© 2018-至今 liruilonger@gmail.com, 保持署名-非商用-相同方式共享(CC BY-NC-SA 4.0)